Walkthrough

This PR introduces relation-level default detection to the schema system. It adds a hasDefault flag to RelationInfo that indicates when all foreign key fields in a relation have default values, updates schema field helpers to consider this new metadata, and includes an end-to-end test suite validating default authentication behavior with generated schema models (User, Profile, Address).

Changes

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

• packages/sdk/src/ts-schema-generator.ts: Verify FK field tracking logic correctly identifies all referenced fields and that hasDefault emission triggers only when all FK fields have defaults.
• packages/schema/src/schema.ts: Confirm the updated FieldHasDefault and FieldIsRelationArray logic correctly integrate relation defaults without breaking existing field-level default detection.
• Test schema files: Validate that generated schema correctly reflects the hasDefault metadata and that the end-to-end test properly exercises the auth-based default scenario across multiple relations.

Possibly related PRs

• feat: many-to-many relations #15: Modifies TsSchemaGenerator.createRelationObject for relation name handling; shares same generator method as this PR's FK tracking changes.
• fix: prisma schema generation issue with default() using auth() #278: Fixes detection of auth()-based defaults and their propagation into relation metadata; directly related to the auth-default feature tested here.
• merge dev to main #96: Refactors TsSchemaGenerator flow and outputs; overlaps with the generator changes in this PR.

Poem

🐰 A hop through relations so fine,
Where defaults align with each foreign line,
Auth IDs dance where users must go,
Profile and Profile together do flow!
hasDefault flags bright, now the schema will know.

Pre-merge checks and finishing touches

Learnt from: ymc9
Repo: zenstackhq/zenstack-v3 PR: 319
File: packages/runtime/src/client/executor/zenstack-query-executor.ts:63-72
Timestamp: 2025-10-21T16:09:31.218Z
Learning: In ZenStack, TypeDefs can be inherited by models. When a TypeDef contains fields with `map` attributes, those mapped field names need to be processed by the QueryNameMapper since they become part of the inheriting model's schema. Therefore, when checking if a schema has mapped names (e.g., in `schemaHasMappedNames`), both `schema.models` and `schema.typeDefs` must be inspected for `@map` and `map` attributes.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Claude finished @ymc9's task —— View job

Code Review Complete ✅

Reviewing PR #371: "fix(orm): typing issue with relation fields with fk having default value"

Todo List:

• Read and analyze all changed files
• Review core schema generation changes
• Analyze TypeScript schema generator modifications
• Review test implementation and coverage
• Assess code quality and best practices
• Check for potential bugs or security issues
• Provide comprehensive feedback

Review Summary

This PR successfully addresses a TypeScript typing issue with relation fields that have foreign keys with default values. The implementation is well-structured and comprehensive.

Key Changes Analyzed

1. Core Schema Enhancement (packages/schema/src/schema.ts:55)

• Enhancement: Added hasDefault?: boolean property to RelationInfo type
• Impact: Enables tracking whether all foreign key fields in a relation have default values
• Assessment: ✅ Clean, minimal API extension that maintains backward compatibility

2. Schema Generator Logic (packages/sdk/src/ts-schema-generator.ts:740-749)

• Enhancement: Added logic to detect when all FK fields have default values:

  if (fkFields.length > 0) {
      const allHaveDefault = fkFields.every((fieldName) => {
          const fieldDef = field.$container.fields.find((f) => f.name === fieldName);
          return fieldDef && hasAttribute(fieldDef, '@default');
      });
      if (allHaveDefault) {
          relationFields.push(ts.factory.createPropertyAssignment('hasDefault', ts.factory.createTrue()));
      }
  }

• Assessment: ✅ Robust implementation with proper field resolution and default detection

3. Test Coverage (tests/e2e/orm/schemas/default-auth/)

• ZModel Schema: Realistic test case with userId Int @unique @default(auth().id)
• Generated Schema: Properly shows hasDefault: true for the user relation (schema.ts:65)
• Integration Test: Validates that Profile creation works without requiring userId field
• Assessment: ✅ Comprehensive test coverage including both unit and integration tests

Code Quality Assessment

Strengths:

1. Type Safety: The FieldHasDefault utility type correctly handles relation defaults (schema.ts:257-258)
2. Proper Logic: FK default detection correctly checks all fields in the relation
3. Test Quality: Test covers the exact use case - creating Profile without specifying userId
4. Schema Generation: Generated TypeScript schema properly reflects the hasDefault flag

Technical Soundness:

• ✅ Logic: The allHaveDefault check ensures ALL FK fields must have defaults (not just some)
• ✅ Type System: The schema type system properly propagates the hasDefault information
• ✅ Edge Cases: Handles optional FK fields and complex relation scenarios

Security & Performance

Security: ✅ No Concerns

• Changes are purely type-system related
• No runtime behavior changes that could introduce vulnerabilities
• Auth default handling (@default(auth().id)) is already secure

Performance: ✅ No Impact

• Schema generation is build-time only
• Runtime performance unaffected
• No unnecessary iterations or expensive operations

Potential Issues: None Identified

The implementation is solid with no apparent bugs or edge cases missed.

Recommendations for Future

1. Documentation: Consider adding JSDoc comments to the hasDefault property in RelationInfo
2. Edge Case Testing: Future tests could cover mixed scenarios (some FK fields with defaults, some without)

Final Assessment: ✅ APPROVED

This is a well-implemented fix that:

• Solves the specific typing issue with relation FK defaults
• Maintains backward compatibility
• Includes comprehensive test coverage
• Follows established code patterns
• Has no security or performance concerns

The code quality is high and the solution is technically sound.